QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/digital/940087.txt

Internet Message Format | 1994-11-13 | 23KB

Date: Wed, 30 Mar 94 04:30:23 PST
From: Ham-Digital Mailing List and Newsgroup <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: Ham-Digital Digest V94 #87
To: Ham-Digital


Ham-Digital Digest          Wed, 30 Mar 94       Volume 94 : Issue   87

Today's Topics:
                                DGMSK?
                       HF Throughput Revisited
                mailgateway Packet Radio <--> Internet
                    Newbie Q: obtaining IP address
                    NTS traffic on packet (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Ham-Digital Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 28 Mar 94 18:16:00 GMT
From: dog.ee.lbl.gov!agate!library.ucla.edu!news.mic.ucla.edu!unixg.ubc.ca!nntp.cs.ubc.ca!utcsri!newsflash.concordia.ca!canopus.cc.umanitoba.ca!mona.muug.mb.ca!mwcsinc![e-mail]
Subject: DGMSK?
To: [e-mail]

ÿ@TO     :[e-mail]                                   N
-> What kinds of high speed packet data are allowed? Are there
-> regulations on what kind of data modulation is employed for packet
-> operation?
->
-> A whole bunch of old 9600bps data radios have become
-> available......they do something like DGMSK or letters to that
-> effect....and immediately its said that's illegal.  because its not
-> AFSK...and the units don't do AX.25.

Rubbish.   Read RIC 24 and RIC 25.   You can't use a secret code - any
coding done to improve information handling is OK, if you're using
something unusual you should be prepared to explain how it works to
the local DOC.   You must faithfully observe the bandwidth limitiations
in the table.  You must of course not use frequencies below 50 MHZ if
you don't know how to send Morse.  Aside from that, there is no
restriction on what you can use ( in Canada) for amateur radio data.
The US rules are written more for the benefit of lawyers and hams but
their problems need not concern you; and from what I've read the only
restrictions they have is that 3rd party traffic handled by an
unattended station must use AX.25 - they also have some baud rate
restrictions.   Local rules only, don't apply to you, have fun.   Get
a G3RUH or K9NG modem from TAPR, couple of old radios, and leave 1200
in the dust.
Bill
ve4stw

----
Muddy Waters Computer Society Inc. Winnipeg, Manitoba, Canada
[phone],08,09 [phone] [phone] (all nodes USR 16.8K D/S)

------------------------------

Date: 29 Mar 94 18:32:55 GMT
From: agate!howland.reston.ans.net!pipex!sunic!psinntp!psinntp!arrl.org![e-mail]
Subject: HF Throughput Revisited
To: [e-mail]

Rick Whiting ([e-mail]) wrote:
: surprised CLOVER did not do better.]  Based on this and other
: published data, the throughput (CPS) for various protocols on HF
: would appear to line up as follows: AX.25 Packet 4, AMTOR ARQ 5,
: RTTY 6, PacTOR 9-10, CLOVER 16, and G-TOR 24.

: By the way, I don't think the Kantronics KAM used in Westhuizen's
: tests implemented hardware ADC Memory ARQ. Furthermore, the

No, it doesn't.  But it's debatable how much difference that makes.
Kantronics says they haven't been able to measure a difference,
although they also say their testing hasn't been extensive on this
point.

: various throughput data cited above were not taken by the same
: experimenters under similar conditions, etc.

Right, which makes the comparison very much apples and oranges.  Given
the massive variations in HF conditions fram band to band, location to
location, season to season and, often, minute to minute, you need a lot
more data than this to make any useful comparisons!  Plus, three of
these protocols are adaptive. (Clover is bit-rate adaptive, PACTOR and
G-TOR are bit- and symbol-rate adaptive.) Thus it is crucial to factor
in the channel conditions, since throughput will vary, probably non-
monotonically, with channel degradations of various types and
combinations.  That way, you can determine which protocols favor which
propagation conditions, and by how much.  Or you can factor *out* the
channel conditions by taking a lot of data that span the (reasonable)
range of channel conditions to get a "figure of merit" for each
protocol.  But since none of that has been done--or published, at any
rate--the conclusions you can draw from the given data are nonexistant.

And the term "throughput" itself is a bit slippery here.  How do you
count the characters that RTTY or AMTOR "receive" but which are not the
characters that were sent?  Seems unfair to the protocols that provide
data integrity to count garbled characters the same.  Bottom line:
comparing error-free protocols with RTTY/AMTOR is comparing not just
apples and oranges, but two entirely different food groups!

That said, there is plenty of evidence, both analytical and empirical,
that suggests that any non-adaptive, non-FEC protocol is going to
perform worse on HF, in general, than an adaptive protocol with FEC.
Plus, I suggest that any protocol that allows undetected errors in
reception is a nonstarter for serious HF communications in the 1990s.
(Although they are fun to play with, and I certainly don't discount
that.) Taking those two factors together, I suggest that the protocols
whose throughput is of interest are PACTOR, CLOVER and G-TOR, in no
particular order.  The others are suitable only for play.

: Of course, there are many features that differentiate the different
: protocols beside typical throughput, not the least of which is
: throughput normalized to bandwidth, i.e., CPS per hertz.  And the

Yes, and isn't it interesting that the one with the widest bandwidth
supports the lowest throughput?  (Even though the data above isn't
particularly useful, I feel confident in saying that any test under
conditions other than excellent will show AX.25 to be a loser.)
--
Jon Bloom KE3Z   [e-mail]

------------------------------

Date: Mon, 28 Mar 94 06:56:18 MST
From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!cs.utexas.edu!asuvax!ennews!stat![e-mail]
Subject: mailgateway Packet Radio <--> Internet
To: [e-mail]

> > I have read in the newsgroup rec.radio...
> > in Amerika you have a mailgateway between Packet-Radio
> > and Internet.


                             How to Use the WB7TPY
                          Packet <-> Internet Gateway

First, some brief operational notes:

(1) Messages must not contain any foul language, or commercial purpose.
(2) Messages can only be sent to countries that the United States has
    a third-party agreement.  All others will be destroyed.
(3) Messages from the internet should be less then 5K in length.
    No files should be sent.
(4) If you have questions, please do not hesitate to contact me either on
    packet radio: [e-mail]       -or-
    Internet    : [e-mail]


(5) Have fun.  Use the gateway as much as you like.  That is what it is
    there for.

                                    ------
                            From Internet to Packet
                                    ------


Send mail to the internet address of:

[e-mail]

The first line of text must contain a full packet address, preceded with the
word "Packet:"

For example, mail to my packet address, would have the first line of text;

Packet: [e-mail]


** NOTE: this line MUST be left justified.

                                    ------
                            From Packet to Internet
                                    ------

Send as private mail (never a bulletin) to the packet address of:

[e-mail]

The first line of text must contain a full domained internet address,
proceeded with the word "Internet:"

For example, mail to my internet address, would have the first line of text;

Internet: [e-mail]



---
Editor, HICNet Medical Newsletter
Internet: [e-mail]                 FAX: [phone]
Bitnet  : ATW1H@ASUACAD

------------------------------

Date: 30 Mar 94 00:40:39 GMT
From: dog.ee.lbl.gov!agate!msuinfo![e-mail]
Subject: Newbie Q: obtaining IP address
To: [e-mail]

Apologies for the Newbie question, but...

I am thinking about trying to set up NOS on the Club machine here at
MSU. I think I can figure out how to get the software set up, but I
have three questions:

1. Where do I get an IP address for our machine?
2. Where do I get a host file so that our machine knows about
   others on the net?
3. How do I propagate our IP address and hostname so that other
   systems know about it and where it is on the net?

Thanks for any help. Responses via email are fine.

/Matthew

--
Matthew Cravit, N9VWG               | All opinions expressed here are
Michigan State University           | my own. I don't speak for MSU
E-Mail: [e-mail]         | and they don't speak for me.
GO/CS -d+@ -p+ c++ !l u+(++) e+(*) s/+ n+(---) h+ f+ !g w+(+++) t++@ r(+) y?

------------------------------

Date: Tue, 29 Mar 1994 15:01:46 GMT
From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!europa.eng.gtefsd.com!emory!nntp.msstate.edu!olivea!news.bu.edu!att-in!att-out!cbnewsh![e-mail]
Subject: NTS traffic on packet
To: [e-mail]

     Here's my two cents on a subject near and dear to my heart.

Tod|> I am advised by local packet network managers and the local NTS
Tod|> representatives that NTS traffic fares poorly on the packet network. The
Tod|> problem is one of "culture"
Tod|> The traffic culture was built around HF operations - originaly spark, then
Tod|> cw , then voice and cw. When digital modes appeared, particularly AMTOR,
Tod|> the NTS began to incoporate that mode for traffic. The traffic culture is
Tod|> based upon one person handing traffic to another and the second person
Tod|> agreeing to forward or deliver the traffic. The Q-signals reflect this
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  That's the key.  in the old NTS, the recipient, by virtue of taking traffic,
  agrees to "forward or deliver" .   A destination bbs, by contrast, has no
  obligation to forward or deliver.  It simply waits for someone to "come
  and get it".  It could wait forever.

Hank>It is not "sent to a callsign", nor is it "placed in a file", it is sent
Hank>to a zipcode, and is then picked up and delivered by *any* NTS person who
                               ^^^^^^^^^^^^^^^^^^^^^^^
   picked up by who?  There are not that many people interested in picking
   up messages off a bbs and delivering them to the general public.

Hank>wishes to do so.  If any NTS message is "stuck" at some BBS, the problem
Hank>lies with the NTS organization. One needs to think of the packet BBS system
Hank>just like any other transport system. It needs to be serviced.

  Very true, but in reality, both Tod and Hank have said the same thing.
  Although the mechanism is there to move traffic on packet, the culture
  is not.

Tod|> Most BBS operators implore those who check in to look at the accumulation
Tod|> of NTS messages and accept one or more that they are willing to relay or
Tod|> deliver. The problem is that there is not a habit pattern or culture
Tod|> that has grown up within the packet community to accept such activity as
Tod|> something of interest. In some cases, the persons checking in may not have
Tod|> HF priviledges that permit them to off-load the messages to the local
Tod|> traffic nets.

Hank>This is an NTS problem, not a packet network problem.
Hank>Why would one offload NTS traffic onto HF?  This is exactly what the BBS
Hank>system is good at; moving bunches of traffic from point A to point B
Hank>without error for any user who wishes to use it.

     In my area, the vast majority of traffic which is removed from the bbs'
     is brought to a 2meter or 80/75meter net for delivery.  This is because
     there are just not enough interested message deliverers to cover an
     entire section or state.

     Hank, the problem is that messages are not sent to a specific "user" at
     the receiving end.  They are broadcast.  Messages sent to some destinations     have about as much chance for success as a CQ on 10 meters at
     the sunspot nadir.  In the old NTS, all messages are handed to a specific
     user, the next person in the pipeline, until the last person is reached.

Tod|> In summary, this is an interesting situation which perhaps offers an
Tod|> opportunity for public service. If such a culture were developed, it would
Tod|> be in place ready to go in the event of an emergency. Regrettably, to date
Tod|> the right ingredients have not come together.

Hank>The opportunity has been there for ten years now.  The BBS system has
Hank>worked in the same way with respect to NTS traffic since at least late
Hank>1984. NTS has failed totally to take advantage of the resource available to
Hank>them, at least in most areas of the country. NTS must understand that the
Hank>average BBS sysop is *not* part of NTS, and has *no* particular interest in
Hank>NTS messages per se. These messages are treated like any other traffic;
Hank>moved to their destination by the quickest method possible. They key thing
Hank>that NTS *must* do to make use of the network is to assign liason staff to
                                                         ^^^^^^^^^^^^^
     a great idea ...IF  you can find enough interested people.

Hank>the network. This has been done since 1986 in New England, and it works
Hank>fairly well.  Speaking for the area in which I now live, NTS folks are

   Frankly, if your sole traffic-handling activity is just picking messages
   off a bbs that you can deliver toll-free, you are going to get bored
   real quickly.  The NTS "culture" has been built for years around
   participation in the pipeline, as an integral part of it.  The packet bbs
   system has taken away the pipeline from the NTS'er and left nothing but
   simple unchallenging user interfaces at either end. No wonder NTS'ers are
   not interested.  It's going to take a long time to develop a culture
   of message deliverers, as opposed to traffic network operators.

   (By the way, I participate in both facets of the hobby, lest you
    suspect bias.)
--
Dan Ostroy                                                         - K2UL -
AT&T Bell Labs, Holmdel, NJ  USA  908-949-5922       [e-mail]

------------------------------

Date: Tue, 29 Mar 94 19:06:51 GMT
From: netcomsv!netcomsv!skyld![e-mail]
Subject: NTS traffic on packet
To: [e-mail]

In article <2n9j6k$[e-mail]> [e-mail] writes:

  > This reply is directed to anyone who is taking part in this discussion.
  >
  > The problems I see with the end delivery of packet nts traffic are:
  >
  > 2.  Some BBS systems do not allow a person to 'kill' a message once
  >     it's been read for delivery.  I WILL NOT deliver traffic from
  >     such a board as it's embarrassing to attempt delivery when
  >     someone else has already done so.

  JNOS (wg7j main author) allows anyone to kill mail in an area with NTS
  prefacing it. (Areas as opposed to listing by topic)

  So there are three catagories of areas now on my system, private (you
  have to be that person to read/kill) public (anyone can read, but sysop
  only to kill) and NTS (anyone can read and then kill).

  > So, can present BBs software be configured to forward nts traffic
  > to a given station, preferably re-address it to that Amateur's
  > call sign so they know there is messages waiting?  Can it be set
  > up to send it to a different person each day, with maybe a different
  > person on odd or even weeks (don't want to leave out anyone who
  > wants to play)?

  A simple entry in the alias file will forward to whomever. so if I
  alias 90505 to kf6pu@wb6ymh.#soca first the alias file redirects it
  to kf6pu, the my rewrite file queues it up for delivery to the wb6ymh
  bbs.

  > BTW, thanks to all the BBS sysops out there that keep the boards
  > up and running.  I know it's a big job and a lot of work.

  It is, but it is one of the ways to return something to the hobby.
  I'll leave it to some of our other members to do the take-take-take
  routine.

  73 es GM from Jeff


 Amateur: WA6FWI@WA6FWI.#SOCA.CA.USA.NOAM | "You have a flair for adding
Internet: [e-mail]        |  a fanciful dimension to any
 US Mail: PO Box 4425 Carson, CA 90749    |  story."
   Phone: [phone]                |           Peking Noodle Co.

------------------------------

Date: 29 Mar 94 16:26:10 GMT
From: agate!howland.reston.ans.net!europa.eng.gtefsd.com!emory!wa4mei!ke4zv![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Reply-To : [e-mail] (Gary Coffman)
Subject : Re: NTS Only BBS? (was Re: [REPOST] NTS Traffic on Packet)

In article <[e-mail]> [e-mail] (Kevin Anderson -7325) writes:
>(2) I how much time, effort, and cost is involved in running a BBS?
>
>I ask not to point any fingers, but because I can't fathom what
>the costs would be.  I can think of there being the expense for
>a good antenna, a reasonable 2m rig (50 watts?), a reasonably
>fast computer (486 of some flavor) with a decent size hard disk,

Gad! What do you think a packet BBS is, a major internet node on
T1 trunks? An original IBM AT (8 MHz 286 with a 20 Mb hard disk)
is beaucoup plenty computer to deal with the 1200 baud half duplex
demands of VHF packet, or the 300 baud demands of HF packet. The
main thing the computer needs is *patience*, and machines, even
old machines, are good at that. What you do need is good radio
equipment, excellent antennas, and in the case of VHF a very
good high site for user access and forwarding. Likely you'll
have several radios on several frequencies for user traffic
and BBS to BBS forwarding.

>that this power-hungry computer (400 VA watts?) would be running
>24 hours a day, your time and effort in seeing that the computer
>and radio keep running.  I suspect MUCH IS already being given
>by BBS operators as a service, but I'm just curious of the
>accounting.

The major cost of operating a full service BBS is *time*. It takes
hours a day to manage the system and deal with naive users. There
are routing databases to maintain, rewrite files to update, manual
rerouting of naive user Email attempts, etc, etc, etc. Many Sysops
keep spare radios and antennas, and spare computers, in order to
maintain service in the event of downtime due to equipment failure.
The wear and tear on the radio equipment is considerably higher
than what most amateur grade equipment was designed to withstand.
Since it's 24 hr operation, good lightning protection is a must.

Gary
--
Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary
Lawrenceville, GA 30244     |                     |

------------------------------

Date: Mon, 28 Mar 1994 17:17:42 GMT
From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!sdd.hp.com!portal.com!portal!combdyn![e-mail]
To: [e-mail]

References <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject : Re: KPC-3 and TCPIP

In article <[e-mail]> [e-mail] (Nathan C. Burnett - N8MBK) writes:
>[e-mail] (Daniel T Senie) writes:
>
>
>>Could you elaborate on this last comment? Obviously the KPC-3 is 1200 only,
>>but it has software (open squelch) DCD available (just issue a command) and
>>has KISS mode. Did you experience problems with either of these things?
>
>iYes the KPC-3 does have KISS mode however I prefer to run a KISS only EPROM
>so I don't have to put it in KISS everytime I want to use it.  Also the DCD
>detection provided by the TAPR DCD mod is IMHO far superior to that of the
>KPC-3's software DCD.
>
Hmm, when I had the KPC-3 on my system....I put it into KISS mode, and left
it that way....never had to tell it to go into KISS mode again during use.

I'm now running a DRSI DPK-2 and a AEA PK88, both with the normal ROMs...I
put them into KISS using a terminal...and I have never taken them out of KISS.

I can't comment on the superiority of the TAPR DCD mod to the software DCD,
I ordered one a few weeks ago, and it hasn't arrived yet.  But, I'll say the
software DCD is better than nothing.  The squelch on one radio likes to walk...
the other day it tightened up so I couldn't hear anything.....so the system
just kept polling every second messing up the network.  The week before, the
squelch opened up and my system couldn't transmit......

--
 WORK: [e-mail]      | PHONE [phone] | FAX [phone] | VE6LKC
 HOME: [e-mail] |       403 526 6019 |     529 5102 | VE6PAQ
 ----------------------------------------------------------------------------
 Praxis BBS - 529 1610 | CYSNET BBS - 526 4304 | Lunatic Haven BBS - 526 6957
 ----------------------------------------------------------------------------
 disclamer = (working_for && !representing) + (Combustion Dynamics Ltd.);

------------------------------

End of Ham-Digital Digest V94 #87
******************************